Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000004_owner-urn-ietf _Sat Aug 3 14:14:15 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA06131 for urn-ietf-out; Sat, 3 Aug 1996 14:14:15 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA06122 for <[e-mail]>; Sat, 3 Aug 1996 14:14:13 -0400
Received: from rock.west.ora.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA10762  (mail destined for [e-mail]); Sat, 3 Aug 96 14:14:09 -0400
Received: (from terry@localhost) by rock.west.ora.com (8.6.13/8.6.11) id LAA01004; Sat, 3 Aug 1996 11:09:48 -0700
Message-Id: <[e-mail]>
From: Terry Allen <[e-mail]>
Date: Sat, 3 Aug 1996 11:09:48 PDT
In-Reply-To: Lewis Girod <[e-mail]>
       "Re: [URN] re NAPTR, URN-res-req" (Aug  1,  7:22pm)
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: Lewis Girod <[e-mail]>, [e-mail]
Subject: Re: [URN] re NAPTR, URN-res-req
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Terry Allen <[e-mail]>
Errors-To: [e-mail]

(Slightly out of order.)  Lewis Girod:

| True.  Our omission of an explanation of hints has caused a great deal
| of confusion, which this reply has hopefully addressed to a degree.
| Since we did not have a clear technical plan at the time of writing we
| did not want to do into a lot of detail; we hoped to instead get out
| some ideas we were plaing with and see what sort of reactions were
| generated.  As for the idea of `hints in reverse', the URN community
| should decide if this is within the scope of our problem or whether we
| want to declare it outside.  My opinion is that it is outside; it
| widens the problem and makes the primary technique for resolution
| (i.e. precomputed lexical generalization of URNs) impossible.

Okay with me if it is to be considered out of scope, although I think
that for some classes of resources straight URN lookup will not be
the most common method of retrieval.

| We used the term ``hint'' to mean precisely the data formats used by
| the system to transmit to the client information that aids in locating
| a document given a URN.  Much of our document was intended to be a set
| of general issues and requirements that we thought were critical to
| producing a working URN system; for this reason we did not want to
| specify formats there.  I don't think coming up with formats is too
| difficult; it is more a question of what clients actually understand.
| At the time of writing we had envisioned such formats as the proposed
| NAPTR and SRV records as possible initial `hint' formats, since if the
| NAPTR system was in use this would be the type of data the clients
| would be expecting.  It should be stated, however, that we were not
| intending hints to solve the sorts of semantics-oriented search
| problems you describe; we see this as a higher level of the problem
| that should be kept separate from the straight URN->document(s)
| mapping problem.

Would you sketch a sample lookup sequence for a URN for which official
and unofficial hints have been injected into the system?  Is it a matter
of user/client preferences as to which hints are heeded?  (See the
Bobsnamespace example below.)

Regarding the "straight URN->document(s) mapping problem," I am suggesting
that the real problem is document identification and retrieval, and that
URNs are only one part of its solution.  But if that's out of scope, okay.

| These concerns are definitely something to think about.  In terms of
| naming authorities disappearing, I had envisioned the solution being
| for the naming authority to transfer or sell off its namespace to
| other entities before going away.  For example, if you have some names
| issued by shady.com, they might sell them to you before they go out of
| business, at which point you would be responsible for telling the
| resolution system where your authoritative server is.  In our model

I am imagining something like this:  Bobsnamespace consists of the
names 1 through 8.  Bob sells off from this name space 2, 4, 5, and 7,
rather than a block of names, and further he declines to resolve them
after he sells them (maybe he goes out of business).  The result
will be (I think) that no one resolver handles the entire name space,
and that it is not possible to predict from the URN which of the
several resolvers for Bobsnamespace should be queried first.

| Another issue that is parallel to this is that the resolution models
| being discussed here all try to deal with URNs in groups in order to
| cut down on the size of higher levels of the database.  NAPTR does
| this in a similar way to the DNS.  The model I tend to think of tends
| to assume that the top level of the directory is pretty big, but still
| is based on the idea of sending all URNs starting with this prefix to
| this particular resolver.  In the end this is a good idea because it
| allows changes to be made at a local level rather than having to
| bother the top level every time.  This means that the system we are
| talking about does not deal with individual URNs under normal
| circumstances; they will always be generalized somehow, in my mind
| usually through the concept of a naming authority.

This will work for some, perhaps a great many, URN lookups, but not
all.

Further, it won't be possible to prevent people from inventing name
spaces that don't decompose nicely.  The top-level URN name space
registry can't refuse to register such name spaces, or it ceases to
be useful.  In addition to grandfathering, there's a requirement to
be able to "cousin-in" name spaces invented by people who weren't
aware they weren't following the rules preferred by the top-level
registry.  These may have to be resolved by brute force (matching
the entire URN string) or use of other info.



Regards,

--
       Terry Allen      O'Reilly & Associates, Inc.   [e-mail]
 "In going on with these experiments, how many pretty systems do we build,
  which we soon find ourselves obliged to destroy?"  -  Benjamin Franklin
        A Davenport Group sponsor     http://www.ora.com/davenport/